The need for effective network security is growing in importance each year due to an increasing occurrence and sophistication of computer hacking, viruses, and other types of network attacks. Electronic commerce has introduced a new type of network attack known as a Denial-of-Service or DoS attack. In a DoS attack, it is possible for a malicious third party to inject or “fold” a false packet into the packet stream when using the standard Transmission Control Protocol or TCP to provide sequenced transmission of data between two applications. To escape detection by secure protocols riding above TCP (e.g., Secure Sockets Layer or SSL or Transport Layer Security or TLS), the false packet is well formed in that it includes a correct address pair and sequence number (so that the packet appears to be valid) but includes spurious data. When the correct packet later arrives, the packet is discarded as a retransmitted duplicate. Because the spurious packet fails to authenticate successfully, the secure protocols terminate the session by sending an error message to the sending node. The secure protocols have no way to request, selectively, a retransmission of the discarded (correct) data. Consequently, the DoS attack necessitates a reestablishment of the TLS connection through a long cryptographic negotiation session, which requires significant processing resources. DoS attacks not only needlessly consume processing resources but also cost electronic commerce businesses millions each year in lost revenue.
One approach employed to defeat DoS attacks is to use IP Security or IPSec protocols in the transport mode to authenticate each IP packet. IPSec is able to encrypt not only the actual user data or payload but also many of the protocol stack informational items that may be used to compromise a customer site in a technical session attack profile. IPSec operates as a “shim” between layer 3 (Internet Protocol on “IP”) and layer 4 (TCP or UDP) of the Open Systems Interconnect or OSI Architecture and includes a suite of protocols, which collectively provide for an Authentication Header (AH), an Encapsulating Security Payload (ESP), and the Internet Key Exchange (IKE). IPSec provides address authentication via AH, data encryption via ESP, and automated key exchanges between sender and receiver nodes using IKE.
FIG. 2A shows an IPv4 packet 200 with an authentication header 204. The authentication header 204 includes a next header field 208 (which is one byte long and identifies the higher level protocol that follows the AH), the payload length field 212 (which is one byte long and specifies the length of the Authentication data field 216), the Reserved field 220 (which is two byte field reserved for future use), the Security Parameters Index or SPI field 224 (which is four bytes long and identifies the security protocols being used in the packet), the sequence number field 228 (which is four bytes long and serves as a counter that identifies the number of IP AH packets it has already received that bear the same destination and SPI data), and the authentication data field 216 (which is of variable length and contains the Integrity Check Value or ICV (which is a digital signature of a packet generated using, for example, DES, MD5, or the Secure Hash Algorithm (SHA-1))).
FIG. 2B shows an IPv4 packet 250 with an Encapsulating Security Payload or ESP header 254. The encapsulating security payload header includes the SPI and sequence number fields 224 and 228 discussed above, the TCP or User Datagram Protocol (UDP) header 230, the payload data field 258 (which contains the encrypted version of the user's original data), the padding field 262 (which provides for any necessary padding requirements of the encryption algorithm or for byte-boundary alignments), the pad length field 266, (which specifies the number of pad bytes used in the padding field), the next header field 270 (which references the payload data by identifying the type of data contained in the payload data field), and authentication data 274 (which is a digital signature applied to the entire ESP header).
IPSec, however, is unable to pass through firewalls, particularly proxy server firewalls that perform network-address translation or network-address-and-port translations. This problem will be discussed with reference to FIG. 1. Referring to FIG. 1, a firewall (or proxy server) 100 is positioned between a network 104 and various firewall-protected network nodes 108a-n. Each node 108a-n has a corresponding IP address and port number. When a node 108a-n sends a packet out to the network, the firewall may change the IP address only or both the IP address and port number. The new IP address is typically the IP address of a proxy server. Because IPSec operates at layers 3 and 4 and IPSec does not have a facility for port specification, the proxy server's attempt to change the port fails and the packet is not transmitted. The ESP header 254 typically allows IP addresses but not port numbers to be changed. The AH 204, on the other hand, does not typically permit either IP addresses or port numbers to be changed.